Incident Management for Automated Teller Machines

ABSTRACT

A computer system monitors a financial transaction system that contains a plurality of remote transaction machines, e.g., automated teller machines (ATMs). The computer system detects and analyzes whether any of the automated teller machines has an outage, whereby customers may be experiencing failed financial transactions. When an outage occurs, a severity level is selected by processing outage data. For example, the computer system determines a measure of the number of failed transactions and then selects a severity level of the outage from which the appropriate recovery procedure can then be initiated. When the transaction system comprises a plurality of networks, the severity level of an outage may be determined by aggregating or separately processing outage data for the networks. Outage ATMs may be prioritized from the number of corresponding failed transactions, so that the prioritization can be included in an indicator that initiates resolution of the outage.

FIELD

Aspects described herein relate to a computer system that processes information about an outage of a financial transaction system.

BACKGROUND

Customers of financial institutions are becoming more dependent on automated systems for obtaining cash, depositing/withdrawing money to/from accounts, and paying bills. For example, automated teller machines (ATMs) are almost ubiquitous to provide financial transactions for customers. An ATM may enable customers to withdraw cash from one's account, make balance inquiries, and transfer money from one account to another using a plastic, magnetic-strip card with a personal identification number issued by the financial institution.

While automated systems may be more convenient than traditionally staffed locations, automated systems can experience operational problems (often referred as outages) that can disrupt service to customers. Because customers do not have direct contact with a person, automated system outages should be identified and corrected in an expeditious manner to reduce an adverse impact on customers.

BRIEF SUMMARY

The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosure. The summary is not an extensive overview of the disclosure. It is neither intended to identify key or critical elements of the disclosure nor to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description below.

According to traditional systems, the severity of an outage of an automated transaction system may be determined from the number of automated teller machines (ATMs) that are experiencing the outage. However, the number of failed transactions may be dependent on other factors such as the time of day that the outage occurs. For example, transaction activity is typically less at midnight than at noon.

Aspects of the disclosure relate to methods, computer-readable media, and apparatuses for monitoring a financial transaction system that contains a plurality of remote transaction machines, e.g., automated teller machines or cash handling machines. The computer system detects and analyzes whether any of the automated teller machines has an outage, whereby customers may be experiencing failed financial transactions. An outage may be caused for different reasons, both unplanned and planned. An unplanned occurrence may result from a weather-related event that disrupts electrical power to a portion of a transaction system, and consequently some or all or the automated teller machine may not properly support financial transactions for customers. Also, communications through a network with some or all of the automated teller machines may be disrupted, causing an outage between the automated teller machines and a central monitoring and/or control computer. In addition, an outage may occur for planned reasons, e.g., when performing maintenance on the ATMs or communication network. When an outage occurs, the financial provider typically desires to correct the outage as soon as possible to reduce the effect on customers.

According to one or more aspects, a monitoring computer obtains outage status of each ATM of a transaction system. The monitoring computer determines a measure of the number of failed transactions and then selects a severity level of the outage. The appropriate recovery procedure may then be initiated according to the selected severity level.

According to one or more additional aspects, criteria for determining the severity of an outage may be different for planned operations, e.g., scheduled maintenance, versus unplanned events, e.g., network outage.

According to one or more aspects, a transaction system may span a plurality of networks, where each network is supported by a different vendor. The severity level of an outage may be determined by aggregating or separately processing outage data for the networks.

According to one or more aspects, outage ATMs may be prioritized during an outage. The prioritization may be determined from the number of corresponding failed transactions, so that the prioritization can be included in an indicator that initiates resolution of the outage.

Various aspects described herein may be embodied as a method, an apparatus, or as one or more computer-readable media storing computer-executable instructions. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Any and/or all of the method steps described herein may be implemented as computer-readable instructions stored on a computer-readable medium, such as a non-transitory computer-readable medium. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of light and/or electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).

Aspects of the disclosure have been described in terms of illustrative embodiments thereof Numerous other embodiments, modifications, and variations within the scope and spirit of the disclosure will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps illustrated herein may be performed in other than the recited order, and that one or more steps illustrated may be optional in accordance with aspects of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:

FIG. 1 illustrates an example of a suitable computing system environment that may be used according to one or more illustrative embodiments.

FIG. 2 shows an illustrative system for implementing example embodiments according to one or more aspects of the present disclosure.

FIG. 3 illustrates a transaction system with a plurality of automated teller machines according to one or more aspects of the present disclosure.

FIG. 4 illustrates assessing a severity level of a transaction system that is experiencing an outage according to one or more aspects of the present disclosure.

FIG. 5 illustrates a flow chart for assessing outage data for a transaction system according to one or more aspects of the present disclosure.

FIG. 6 illustrates a flow chart for assessing a severity level of a transaction system according to one or more aspects of the present disclosure.

FIG. 7 illustrates a flow chart for determining whether to perform an immediate update within a transaction system according to one or more aspects of the present disclosure.

FIG. 8 illustrates a flow chart for determining a failed customer indicator for a transaction system according to one or more aspects of the present disclosure.

DETAILED DESCRIPTION

In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the disclosure may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope and spirit of the present disclosure.

In accordance with various aspects of the embodiments, a computer system monitors a financial transaction system that contains a plurality of remote transaction machines, e.g., automated teller machines (ATMs) or cash handling machines. The computer system detects and analyzes whether any of the automated teller machines has an outage, whereby customers may be experiencing failed financial transactions. An outage may be caused for different reasons, both unplanned and planned. An unplanned occurrence may result from a weather-related event that disrupts electrical power to a portion of a transaction system, and consequently some or all or the automated teller machine may not properly support financial transactions for customers. Also, communications through a network with some or all of the automated teller machines may be disrupted, causing an outage between the automated teller machines and a central monitoring and/or control computer. Consequently, customers may not be able to complete transactions at an ATM until the outage has been resolved. Planned changes in the surrounding infrastructure that supports the telecommunication equipment/network may also cause a disruption. In addition, an outage may occurred for planned reasons, e.g., when performing maintenance on the ATMs, the telecommunication network/equipment, or the infrastructure that supports the telecommunication network/equipment. When an outage occurs, the financial provider typically desires to correct the outage to reduce the effect on the customers.

FIG. 1 illustrates an example of a suitable computing system environment 100 that may be used according to one or more illustrative embodiments. For example, as will be further discussed, computing system environment 100 may support processes 500-800 as shown in FIGS. 5-8, respectively, to support a financial transaction system. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality contained in the disclosure. The computing system environment 100 should not be interpreted as having any dependency or requirement relating to any one or combination of components shown in the illustrative computing system environment 100.

The disclosure is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the disclosed embodiments include, but are not limited to, personal computers (PCs), server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

With reference to FIG. 1, the computing system environment 100 may include a computing device 101 wherein the processes discussed herein may be implemented. The computing device 101 may have a processor 103 for controlling overall operation of the computing device 101 and its associated components, including random-access memory (RAM) 105, read-only memory (ROM) 107, communications module 109, and memory 115. Computing device 101 typically includes a variety of computer readable media. Computer readable media may be any available media that may be accessed by computing device 101 and include both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise a combination of computer storage media and communication media.

Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include, but is not limited to, random access memory (RAM), read only memory (ROM), electronically erasable programmable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by computing device 101.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Modulated data signal includes a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

Computing system environment 100 may also include optical scanners (not shown). Exemplary usages include scanning and converting paper documents, e.g., correspondence and receipts to digital files.

Although not shown, RAM 105 may include one or more are applications representing the application data stored in RAM 105 while the computing device is on and corresponding software applications (e.g., software tasks), are running on the computing device 101.

Communications module 109 may include a microphone, keypad, touch screen, and/or stylus through which a user of computing device 101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output.

Software may be stored within memory 115 and/or storage to provide instructions to processor 103 for enabling computing device 101 to perform various functions. For example, memory 115 may store software used by the computing device 101, such as an operating system 117, application programs 119, and an associated database 121. Also, some or all of the computer executable instructions for computing device 101 may be embodied in hardware or firmware.

Computing device 101 may operate in a networked environment supporting connections to one or more remote computing devices, such as computing devices 141, 151, and 161. The computing devices 141, 151, and 161 may be personal computing devices or servers that include many or all of the elements described above relative to the computing device 101. Computing device 161 may be a mobile device communicating over wireless carrier channel 171.

The network connections depicted in FIG. 1 include a local area network (LAN) 125 and a wide area network (WAN) 129, but may also include other networks. When used in a LAN networking environment, computing device 101 may be connected to the LAN 125 through a network interface or adapter in the communications module 109. When used in a WAN networking environment, the computing device 101 may include a modem in the communications module 109 or other means for establishing communications over the WAN 129, such as the Internet 131 or other type of computer network. It will be appreciated that the network connections shown are illustrative and other means of establishing a communications link between the computing devices may be used. Various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like may be used, and the system can be operated in a client-server or in Distributed Computing configuration to permit a user to retrieve web pages from a web-based server. Any of various conventional web browsers can be used to display and manipulate data on web pages.

Additionally, one or more application programs 119 used by the computing device 101, according to an illustrative embodiment, may include computer executable instructions for invoking user functionality related to communication including, for example, email, short message service (SMS), and voice input and speech recognition applications.

Embodiments of the disclosure may include forms of computer-readable media. Computer-readable media include any available media that can be accessed by a computing device 101. Computer-readable media may comprise storage media and communication media and in some examples may be non-transitory. Storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, object code, data structures, program modules, or other data. Communication media include any information delivery media and typically embody data in a modulated data signal such as a carrier wave or other transport mechanism.

Although not required, various aspects described herein may be embodied as a method, a data processing system, or a computer-readable medium storing computer-executable instructions. For example, a computer-readable medium storing instructions to cause a processor to perform steps of a method in accordance with aspects of the disclosed embodiments is contemplated. For example, aspects of the method steps disclosed herein may be executed on a processor on a computing. device 101. Such a processor may execute computer-executable instructions stored on a computer-readable medium.

Referring to FIG. 2, an illustrative system 200 for implementing example embodiments according to the present disclosure is shown. As illustrated, system 200 may include one or more workstation computers 201. Workstations 201 may be local or remote, and may be connected by one of communications links 202 to computer network 203 that is linked via communications links 205 to server 204. In system 200, server 204 may be any suitable server, processor, computer, or data processing device, or combination of the same. Server 204 may be used to process the instructions received from, and the transactions entered into by, one or more participants.

Computer network 203 may be any suitable computer network including the Internet, an intranet, a wide-area network (WAN), a local-area network (LAN), a wireless network, a digital subscriber line (DSL) network, a frame relay network, an asynchronous transfer mode (ATM) network, a virtual private network (VPN), or any combination of any of the same. Communications links 202 and 205 may be any communications links suitable for communicating between workstations 201 and server 204, such as network links, dial-up links, wireless links, and hard-wired links.

The steps that follow in the Figures may be implemented by one or more of the components in FIGS. 1 and 2 and/or other components, including other computing devices.

FIG. 3 shows transaction system 300 with a plurality of automated teller machines 301-306 according to the present disclosure. Automated teller machine (ATM) 301-306 may be referred to as an automatic teller machine, automated banking machine (ABM), cash machine, or “a hole in the wall.” Automated teller machine 301-306 typically comprises a computerized telecommunications device that provides customers of a financial institution with access to financial transactions in a public space without the need for a cashier, human clerk or bank teller. Using an automated teller machine, customers can access their bank accounts in order to make cash withdrawals, debit card cash advances, and check their account balances as well as purchase prepaid cellphone credit.

A financial institution can interact with automated teller machines 301-306 through a communications network, which is referred to as a network. The financial institution may monitor automated tell machines 301-306 through monitoring computer 312 that executes different applications to monitor transaction system 300. With an aspect of the disclosure, the root cause of an outage may be determined through a triage/troubleshooting procedure. The procedure may determine whether the root cause is improper internal operations (e.g., instability of an application) or a communications outage (e.g., telecommunications network/equipment problem). The severity assignment of the outage may be based only on the impact on the ATMs rather than the root cause.

According to an aspect of the disclosure, communications to different ATMs may be supported by different telecommunications vendors (referred as vendors). For example, communications to ATMs 301-304 and 305-306 are supported by network 309 (vendor 1) and network 310 (vendor 2), respectively. Moreover, automated teller machines 301-306 may be partitioned by regions, e.g., where automated teller machines 301-302, 303-304, and 305-306 are located in regions 307, 308, and 309, respectively. For example, transaction system 300 may span the New York City metropolitan area, where regions 307-309 correspond to Manhattan, Long Island, and northeastern New Jersey, respectively.

According to traditional systems, all automated teller machines 301-306 may be treated equally when determining the severity of an outage. Based on the severity, a vendor of a network assesses the urgency for correcting the outage, typically in accordance with a service level agreement (SLA) between the financial institution and the vendor. While the above approach may be consistent with the service level agreement, this approach might not accurately gauge the customer impact of the outage. The transaction volume may vary for different ATMs and for different times. For example, transaction volume for an automated teller machine located in a city's downtown is typically greater than an automated teller machine located at the outside fringes of the city. Also, traditional systems might not include the effects of the duration of an outage. However, the longer the outage duration, the greater the number of failed transactions, and consequently the greater the customer impact. Also, the transaction volume typically varies with the time of day (e.g., midnight versus noon), day of the week, and so forth.

Monitoring computer 312 may communicate with automated teller machines 301-306 on a periodic basis. When expected communications is disrupted, monitoring computer 312 deems that the corresponding automated teller machine 301-306 is experiencing an outage (which may be referred as an outage ATM). Monitoring computer 312 may gauge the severity of the outage based on the number of outage automated teller machines, the transaction volume of the outage automated teller machines, the duration of the outage, and the like.

With an aspect of the disclosure, monitoring computer 312 may determine the failed customer transactions by accessing data structure 314 to obtain the average transaction volume for the corresponding automated teller machine for the outage time duration. The average transaction volume may then be multiplied by the outage duration to estimate the number of failed customer transaction. For example, if automated teller machine 301-306 has an average transaction volume of 10 transactions per hour, the estimated number of failed customer transactions is 10 when the outage duration is 1 hour and 25 when the outage duration is 2.5 hours.

As will be further discussed, the severity of the outage may be determined from one or more outage parameters, including the number of outage automated teller machines, location of the outage automated teller machines, and/or estimated failed customer interactions. Monitoring computer 312 may then generate an indicator (e.g., a message) to network support system 313 to alert the responsible party to initiate action to correct the outage. As previously discussed, communications to different networks may be supported by different vendors, each having a separate service level agreement. In such a case, the indicator may be sent to support center 313 of the responsible vendor. Moreover, when the outage spans networks 310-311, the severity level may be specific to a network or may be aggregated over all of the networks. In the former case, the severity level may be driven by the service level agreement with the vendor; while in the latter case, the severity level may better reflect the effect over the entire transaction system.

FIG. 4 shows an example chart 400 for assessing a severity level of transaction system 300 that is experiencing an outage according to the present disclosure. An outage may occur for unplanned reasons 405 (e.g., network failure or power outage) or for planned reasons 406 (e.g., maintenance). With some embodiments, mapping the criteria for the number of outage automated teller machines to the severity level may be different for unplanned reasons 405 versus planned reasons 406. Also, the criteria for the number of outage automated teller machines may be further contingent on the duration of the outage.

The severity level 402, 403, or 404 may be based on the number of outage automated teller machines and the estimated failed customer interactions (FCIs) 401. As will be discussed with FIG. 8, monitoring computer 312 determines the estimated failed customer interactions from transaction traffic history data structure 314. However, other outage parameters and/or combinations of outage parameters may be used for determining the severity level. For example, some embodiments may use the ATM location as one parameter in conjunction with other outage parameters, including the outage duration.

In this example, there are three severity levels: first, second, and third severity levels 404, 403, and 402, respectively, where the first severity level has the most urgency. With an aspect of the disclosure, FCI 401 may be determined in different ways. For example, FCI 401 may be based on estimated FCIs or calculated FCIs. Calculated FCIs may be determined in hours, possibly days later after the occurrence by an automated system. The automated system may calculate the estimated loss of transactions based on the transaction volume patterns within each specific ATM. Estimated FCIs may be based on the average number of transactions that occur across or network during peak versus non-peak times. Specific ATM transactions by ATM may not be available real time, so the determination may use a general estimated loss of transactions to assess the FCI impact in order to assign a severity level of the outage. With the example shown in FIG. 4, the urgency for resolving the outage increases with a lower numbered severity level. For example, when the calculated (estimated) FCIs is less than 10,000 transactions or the number of outage automated teller machines is between 25 and 99 ATMs, the outage is determined to be at a third severity level.

With an aspect of the disclosure, the determination of the severity level may consider a single outage and/or multiple outages that have a cumulative impact and/or a regional impact to customers. For example, referring to FIG. 4, the criterion for the second severity level due to a communication outage is 100 to 500 ATMs impacted from a single outage or a cumulative impact greater than 15 minutes over multiple outages.

Referring to an example previously presented with FIG. 3, automated teller machines 301-306 may be partitioned by regions, where regions 307-309 correspond to Manhattan, Long Island, and northeastern New Jersey, respectively. Some embodiments may support different criteria for different regions. Also, the criteria for the entire transaction area (e.g., over combined regions 307-309) may differ from individual regions (region 307 versus region 308 versus region 309) and/or different vendors (regions 307-308 versus region 309). While the criteria may differ from a service level agreement, the criteria may better reflect the perspective of the customers. If the above criteria vary from a service level agreement, a vendor may wish to enhance service for the financial institution. Moreover, the financial institution may wish to modify the service level agreement when the service agreement is renewed to better reflect the customer's perspective.

FIG. 5 shows process 500 for assessing outage data for a transaction system according to the present disclosure. Process 500 may use a set of criteria to create a severity rating that can automate the identification of automated teller machines 301-306 (as shown in FIG. 3) and/or region 305-306 based on a prioritization during an outage.

At block 501, monitoring computer 312 (as shown in FIG. 3) obtains outage data for transition system 300. For example, an outage with automated teller machine 301 may be detected by monitoring when computer 312 is not able to communicate with automated teller machine 301 through network 310. Outage data may include one or more parameters, including the number of failed customer transactions, duration of the outage, and/or location of an automated teller machine. For example, a financial institution may consider a particular automated teller machine to be in a highly strategic location with respect to other automated teller machines.

At block 502, monitoring computer 312 prioritizes the outage automated teller machines and/or regions. For each example, the service area of transaction system 300 may be partitioned into geographic regions 307-309, where each region is served by a subset of automated teller machines (e.g., region 308 served by automated teller machines 303-304 as shown in FIG. 3).

At block 503, monitoring computer 312 generates an indication (e.g., e-mail, short message service (SMS) message, custom message, or the like) that includes the determined prioritization as determined at block 502.

FIG. 6 shows process 600 for assessing a severity level of a transaction system outage according to the present disclosure. At blocks 601 and 602, the number of estimated failed customer interactions (FCI) during the outage and the number of outage ATMs are respectively compared to the FCI and number of outage ATM criteria for the i^(th) severity level. For example, referring to chart 400 shown in FIG. 4, for a communication outage, the FCI range and the outage ATM range for the second severity level are 10,000 to 25,000 FCIs and 100-500 automated teller machines (for down time greater than 15 minutes across a PRO), respectively. When the outage data is within the predetermined ranges, process 600 sets the severity level to the corresponding value at block 603.

While the severity level is based on either comparison at blocks 601 and 602 being true (corresponding to an OR logical function), another type of logic function (e.g., an AND logic function) or a plurality of logic functions may be used to determine the severity level of an outage. Also, other comparison results for other outage parameters may be logically combined to determine the severity level of an outage.

With some embodiments, the outage automated teller machines may be rank-ordered at block 604 based on the estimated failed financial transactions projected for a given ATM. The priority order may provide a preference for re-activating automated teller machines by the responsible party. Based on determined severity level, the appropriate outage procedure may be performed. For example, software may be updated only for the first severity level. Also, the severity level may dictate emergency change protocols that can be implemented to introduce change in the environment. Changes may include the authorization of logical/physical changes of the telecommunications equipment within network 300, internal ATM software changes, internal application/database changes, and external hardware/software changes.

FIG. 7 shows process 700 for determining whether to perform an immediate update within a transaction system according to the present disclosure. At block 701 monitoring computer 312 receives a request to update some or all of the automated teller machines in transaction system 300. For example, maintenance personnel may request to update software that executes on the software to fix known bugs or to enhance the automated teller machine's capabilities. However, updating an automated teller machine may cause unanticipated problems, so the financial institution may authorize the update only when resolving the outage is sufficiently urgent, e.g., with the first and second severity level as determined at block 702. If so, updating is authorized as soon as possible at block 703. Otherwise the update is delayed until a scheduled time at block 704.

With an aspect of the disclosure, process 700 may treat different types of updates differently. For example, ATM software may be updated with first and second severity levels while ATM hardware may be updated only with the first severity level.

FIG. 8 shows process 800 for determining a failed customer indicator for a transaction system according to the present disclosure. At block 801, monitoring computer 312 determines whether to access transaction history data for outage automated teller machines in system 300 from data structure 314 (as shown in FIG. 3). For example, monitoring computer 312 may periodically access transaction history data (e.g., every 15 minutes) during the outage. Data structure 314 may have the historical average transaction activity for each automated teller machine according to the hour, month, and day of the week. At block 802 computer 312 accesses the historical outage data and updates the estimated failed customer interactions at block 803 based on an amount for the incremental duration of the outage. For example, if there are 100 outage ATMs, each having a historical average of 10 transactions per hour, the failed customer interactions is 1000 transactions if the outage continues for 1 hour. If the outage continues for a second hour and if the historical average increases to 15 transactions per hour, the estimated failed customer interactions is 2500 transactions for the outage.

If the historical average varies by automated teller machine, data structure 314 may have outage statistics on a per automated teller machine basis so that the estimated failed customer interactions may be updated on a per automated teller machine basis. Monitoring computer 312 may further prioritize the outage automated teller machines at block 804 according to the contribution of the automated teller machine to the estimated failed customer interaction. Maintenance personnel may then resolve the outage based on the prioritization.

Aspects of the embodiments have been described in terms of illustrative embodiments thereof Numerous other embodiments, modifications and variations within the scope and spirit of the appended claims will occur to persons of ordinary skill in the art from a review of this disclosure. For example, one of ordinary skill in the art will appreciate that the steps illustrated in the illustrative figures may be performed in other than the recited order, and that one or more steps illustrated may be optional in accordance with aspects of the embodiments. They may determine that the requirements should be applied to third party service providers (e.g., those that maintain records on behalf of the company). 

1. A computer-assisted method for assessing a status of a transaction system, the transaction system including a plurality of automated teller machines (ATMs), the method comprising: obtaining, by a processor, an outage status for each of the plurality of automated teller machines from a first data structure stored by a first memory device, wherein the processor interacts with the plurality of automated teller machines through at least one network; determining, by the processor, a measure of failed financial transactions for the transaction system from the outage status; accessing, by the processor, information about a first and second set of criteria from a second data structure stored by a second memory device, wherein the first set of criteria specifies an unplanned outage and the second set of criteria specifies a planned outage of the transaction system, respectively; when the unplanned outage within the transaction system occurs, selecting, by the processor, a severity level for the transaction system based on the first set of criteria for the measure of failed financial transactions; and when the planned outage within the transaction system occurs, selecting, by the processor, the severity level based on the second set of criteria for the measure, wherein the first set and the second set of criteria are different.
 2. The method of claim 1, wherein the outage status is indicative of a communication outage between at least one of the plurality of automated teller machines and the processor.
 3. The method of claim 1, wherein the severity level is based on planned operations for the transaction system.
 4. The method of claim 1, further comprising: updating the transaction system within a time duration only when the severity level has a predetermined value.
 5. The method of claim 1, wherein the transaction system spans a plurality of networks, each network providing communications with a different subset of the plurality of automated teller machines and is supported by a different vendor.
 6. The method of claim 5, further comprising: restricting the obtaining, the determining, and the selecting to one of the plurality of networks.
 7. The method of claim 5, further comprising: aggregating the measure of failed financial transactions for the plurality of networks.
 8. The method of claim 1, wherein the determining comprises: accessing a transaction statistic for one of the plurality of automated teller machines; repeating the accessing for a different automated teller machine; and determining the measure of the failed financial transactions from the accessed statistics.
 9. The method of claim 1, further comprising: revising the measure for a different time duration; and updating the severity level from the revised measure.
 10. The method of claim 1, wherein the selecting is further based on a number of outage automated teller machines.
 11. The method of claim 1, further comprising: rank ordering the outage automated teller machines according to the measure of failed financial transactions for a corresponding automated teller machine.
 12. The method of claim 1, further comprising: generating, by the processor, an indicator, the indicator indicative of a request to correct an outage of the at least one network.
 13. An apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to perform, based on instructions stored in the at least one memory: identifying an outage automated teller machine in transaction system, the transaction system having a plurality of automated teller machines, the apparatus interacting with the plurality of automated teller machines through a network; accessing a transaction statistic for the outage automated teller machine; obtaining a measure of failed financial transactions for the transaction system from the transaction statistic; when an unplanned outage within the transaction system occurs, determining a severity level for the transaction system based on a first set of criteria for the measure of failed financial transactions; and. when a planned outage within the transaction system occurs, determining the severity level based on a second set of criteria for the measure, wherein the first set and the second set of criteria are different.
 14. The apparatus of claim 13, wherein the determining includes further considering a number of outage automated teller machines.
 15. The apparatus of claim 13, wherein the at least one processor is further configured to perform: generating an indicator, the indicator indicative of a request to correct an outage of the network.
 16. The apparatus of claim 15, wherein the at least one processor is further configured to perform: rank ordering the outage automated teller machines based on the measure of failed financial transactions; and including the rank ordering in the indicator.
 17. The apparatus of claim 13, wherein the at least one processor is further configured to perform: revising the measure for a different time duration; and updating the severity level from the revised measure.
 18. A non-transitory computer-readable storage medium storing computer-executable instructions that, when executed, cause a processor at least to perform operations comprising: obtaining, by a processor, an outage status for each of the plurality of automated teller machines, wherein the processor interacts with the plurality of automated teller machines through at least one network of a transaction system; accessing a transaction statistic for an outage automated teller machine; repeating the accessing for all other outage automated teller machines; determining a measure of the failed financial transactions from the accessed statistics; when an unplanned outage within the transaction system occurs, selecting a severity level for the transaction system based on a first set of criteria for the measure of failed financial transactions; and when a planned outage within the transaction system occurs, selecting the severity level based on a second set of criteria for the measure, wherein the first set and the second set of criteria are different.
 19. The non-transitory computer-readable storage medium of claim 18, wherein the computer-executable instructions, when executed, cause the processor to perform: revising the measure for a different time duration; and updating the severity level from the revised measure.
 20. A computer-assisted method for assessing a status of a transaction system, the transaction system including a plurality of automated teller machines (ATMs), the transaction system spanning a plurality of geographical regions, the plurality of geographical regions including a first geographical region and a second geographical region, the method comprising: obtaining, by a processor, outage data outage criteria for the transaction system, wherein the outage criteria is dependent on different geographical regions in the transaction system; determining, by the processor, a first severity level for the first geographical region based on a first criteria for an outage in the transaction system, wherein the first geographical region comprises a first subset of the plurality of ATMs; determining, by the processor, a second severity level for the second geographical region based on a second criteria for the outage, wherein the first criteria and the second criteria are different; prioritizing, by the processor, the plurality of geographical regions of the transaction system based on the outage data, the prioritization indicative of an ordering for correcting an outage of a corresponding region of the transaction system; and generating, by the processor, an indication that includes information indicative of the prioritization.
 21. (canceled)
 22. The method of claim 20, wherein the prioritizing comprises: determining a measure of failed customer transactions for each geographical region of the transaction system; and rank ordering the plurality of geographical regions based on the corresponding measures.
 23. The method of claim 20, wherein the rank ordering is further based on a location of each geographical region of the transaction system.
 24. (canceled)
 25. The method of claim 20 further comprising: determining a combined severity level for the plurality of geographical regions based on a third criterion for the outage, wherein the third criterion is different from the first and second criteria. 